<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="content-type"
 content="text/html; charset=ISO-8859-1">
  <title>Eclipse 3.0 - Concurrent Operations in the UI</title>
</head>
<body>
<h1>Eclipse 3.0 - Concurrent Operations in the UI</h1>
<br>
There is a need to close on the issues regarding progress in Eclipse
3.0. The current support is adequate but we there are some remaining
issues that should be addressed in order to make this new concurrency
work accessible for<span style="font-weight: bold;"> new users</span>, <span
 style="font-weight: bold;">cohesive</span>, and <span
 style="font-weight: bold;">slick</span>!<br>
<h3>Operation kinds</h3>
In the following we need to distinguish between different kinds of
background operations:<br>
<ul>
  <li><span style="font-style: italic;">user initiated</span>: long
running operations: build, rebuild, checkout a project, synchronizing
with the repository, exporting a plug-in, search.<br>
  </li>
</ul>
<ul>
  <li><span style="font-style: italic;">automatically triggered:</span>
user operations: auto build, scheduled synchronize. These are
operations
that have a meaning for an IDE user.<br>
  </li>
</ul>
<ul>
  <li><span style="font-style: italic;">system operations</span>:
operations that are not triggered by the user and can be considered as
an implementation detail.<br>
  </li>
</ul>
<h3>Issues<br>
</h3>
<ul>
  <li>users need a clear indication that a long running operation has
started.</li>
  <li>users need to know when an operation has ended.</li>
  <li>users need to know whether there are interesting new results, or
new information.</li>
  <li>users need to feel in control, i.e., see which operations are
running and they can easily cancel operations</li>
  <li>users need not be surprised by dialogs shown by a background
operation<br>
  </li>
  <li>plug-ins have to consistently shows their results and progress in
the same way.<br>
  </li>
</ul>
<h3>Long running Operation Feedback in 2.1</h3>
In the 2.1 release the users was shown the following feedback for the
different operation kinds:<br>
<ul>
  <li>user initiated long running operations: modal progress dialog</li>
  <li>automatically triggered user operations: the only such operation
was autobuild.delayed modal progress monitor in status line and global
busy cursor</li>
  <li>system operations not visible to the user (e.g. updating the Java
index)</li>
  <li>Results where made available immediatly after the progress dialog
finished (e.g. Synchronize View show, compare dialog shown)<br>
  </li>
</ul>
Observations: the user was often blocked but felt to be in control,
i.e., they can cancel. It is clear when new information is available.<br>
<h3>Long running Operation Feeback in 3.0</h3>
The 3.0 feedback implementation doesn't distinguish between user
initiated and automatically triggered<br>
operations:<br>
<ul>
  <li>&nbsp;user initiated long running operations/automatically
triggered user operations:</li>
  <ul>
    <li>show progress message of active job in the status bar segment</li>
  </ul>
  <ul>
    <li>show unknown progress bar in the status bar</li>
  </ul>
  <ul>
    <li>hovering over the progress status segment shows a window with
all active jobs</li>
  </ul>
  <ul>
    <li>double clicking the status bar segment opens the progress view</li>
  </ul>
  <ul>
    <li>the problem is that the user only sees easily that something is
going on but not what it really is.<br>
    </li>
  </ul>
</ul>
<ul>
  <li>system operations</li>
  <ul>
    <li>some system operations show up in the progress status bar.</li>
  </ul>
</ul>
So how are the progress issues addressed in 3.0:<br>
<ul>
  <li>users need a clear indication that a long running operation has
started.</li>
  <ul>
    <li>no clear indication, In particular it can happen that another
operation in the status bar segment "hides" the user initiated
operation. The user has to hover over the status segment to verify that
the operation has started.</li>
  </ul>
</ul>
<ul>
  <li>users need to know when an operation ended</li>
  <ul>
    <li>to verify that a job has really finished the use has to open
the progress view.<br>
    </li>
  </ul>
</ul>
<ul>
  <li>users need to know whether there are interesting new results, or
new information</li>
  <ul>
    <li>Synchronize operations pop-up a dialog with an option to not
show the dialog again.</li>
    <li>auto build and build don't provide any indication when they are
done.</li>
    <li>users need to feel in control, i.e., the see what is going on
and can easily cancel operations.</li>
    <li>the user doesn't see at a glance what is going on. The status
bar segment is often compressed, e.g.,&nbsp;&nbsp; Performing a
CV...ources: 1% done<br>
      <br>
    </li>
  </ul>
  <li>users need to feel in control</li>
  <ul>
    <li>no real progress bar, unless the user opens the progress
view.&nbsp;</li>
    <li>There is no affordance that there is a progress view.</li>
    <li>canceling requires many more steps than in 2.1 with a modal
progress dialog:</li>
    <ul>
      <li>open the progress view</li>
      <li>select the job</li>
      <li>select cancel from the context menu.<br>
        <br>
      </li>
    </ul>
  </ul>
  <li>users need not be surprised by dialogs shown by a background
operation</li>
  <ul>
    <li>Currently some CVS operations prompt with a modal dialogs at
the end of an operation (e.g. Synchronize complete, Compare, Merge).
This interrupts the users workflow.<br>
      <br>
    </li>
  </ul>
  <li>plug-ins have to consistently shows their results and progress in
the same way.</li>
  <ul>
    <li>in the sdk plug-ins are showing progress in different ways,
search showing progress in the view's title bar and has a cancel
button, synchronize doesn't. <br>
    </li>
  </ul>
</ul>
<h3>Solutions and Alternatives</h3>
The following proposal distinguishes between user initiated and
automatically triggered operations.<br>
<h4>USER INITIATED OPERATIONS</h4>
You don't always want to run an operation in the background. The user
should be in control whether an operation runs in the background. I
often know that I want to wait until an operation is finished (e.g.
checkout a project). In particular, I don't want to poll whether an
operation is finished.<br>
<br>
Therefore the suggestion is to give the user control over whether an
operation should be run in the background.<br>
This should not be done in a preference, but as follows:<br>
<ol>
  <li>the operation starts, but initially it is shown with a "classic"
modal progress dialog.</li>
  <li>the dialog provides a new option to run in the background</li>
  <li>the dialog offers a "don't ask me again" check box (not included
in the screenshot below):<br>
  </li>
</ol>
Once the user decides to run the operation in the background it is
critical that the progress message (including cancel) is still visible.
Options:<br>
<ol>
  <li>make the progress dialog non-modal (as it is done in explorer).
The dialog should become an "accumulating" progress dialog, i.e., if
more than one operation is running, each of them should be shown in the
dialog.</li>
  <li>show the status message in one of the result views. For example,
the build progress would show at the top or bottom of
the&nbsp;&nbsp;&nbsp;
problems view. Search already shows progress in the view's description
([running] "filx.txt" found 1).<br>
  </li>
</ol>
<h4>AUTOMATICALLY INITIATED OPERATIONS</h4>
Consistent with the 2.1 solution an automatically initiated operation
should be non-invasive, i.e., not show a progress dialog. However, they
still need to show, that an operation has started, is in progress, and
when it is done. One suggestion to show a fixed indicator for each of
these operations in the status line (in the Eclipse SDK there is only
auto build, and Synchronize.) <br>
This can be a compact indicator. For example, for auto build this
indicator should show that a build is in progress,<br>
whether it has identified problems. Similarly, the Synchronize
indicator (for scheduled synchronize operaitons )would show whether
there are conflicts. It could be a similar indicator as is used in the
overview ruler of the Java editor, for the error status of a single
compilation unit.<br>
<br>
Double clicking the indicator will reveal the result view, i.e., for a
build the problems view. Hovering over the indicator shows information
like the number of errors, or the number of conflicts for a scheduled
synchronize. The progress of an automatically initiated operation
should be shown in the accumulated progress dialog/control, but it
should not automatically reveal it.<br>
<h4>SYSTEM OPERATIONS</h4>
The current Progress view should become a Jobs view, that is a
debugging aid for plug-in developers. It is not intended for the
end-user, <br>
smiliar as Show View&gt;PDE Runtime&gt;Plug-in Registry.<br>
<h3>Summary</h3>
<ul>
  <li>users need a clear indication that a long running operation has
started.</li>
</ul>
<ul>
  <ul>
    <li>For user initiated actions the modal progress dialog shows up.</li>
    <ul style="color: rgb(255, 102, 102);">
      <li>job creators decide if job is defined as User.<br>
      </li>
    </ul>
    <ul>
      <li style="color: rgb(255, 102, 102);">users have the option of
running in the background which will collapse down into the progress
status line</li>
      <li><span style="color: rgb(255, 102, 102);">there will be a
preference for *always* running in the background</span></li>
    </ul>
    <li>For automatically triggered actions the dedicated status
indicator shows the information that an operation has started.</li>
    <ul>
      <li style="color: rgb(255, 102, 102);">jobs can be scheduled via
a view and views will show busy hint - will work with multiple
workbench windows</li>
      <li><span style="color: rgb(255, 102, 102);">views can be
interested in a certain job familly</span><br>
      </li>
    </ul>
  </ul>
</ul>
<ul>
  <li>users need to know when an operation ended</li>
  <ul>
    <li>the progress dialog is dismissed</li>
    <li><span style="color: rgb(255, 102, 102);">the views tab changes
from italic to either bold (if interesting changes) or back to normal
(if no changes).</span><br>
    </li>
  </ul>
</ul>
<ul>
  <li>users need to know whether there are interesting new results, or
new information</li>
  <ul>
    <li>this isn't addressed by the above. One possible solution is to
show the arrival of new interesting information in the view tab (e.g.
new errors etc.) by bolding its label. The new information indication
is removed when the view is activated.</li>
    <li>Open issue though: how does this work with multiple workbench
windows?<br>
    </li>
  </ul>
</ul>
<ul>
  <li>users need to feel in control, i.e., they see what is going on
and can easily cancel operations.</li>
  <ul>
    <li>a full progress monitor with a cancel button gives the user
control.</li>
    <li><span style="color: rgb(255, 102, 102);">views that are busy
(tab is bolded) users can cancel the background job in the context.
Views decide if they want to support the cancel button. No generic
support form the UI workbench.</span><br>
      <br>
    </li>
  </ul>
  <li>users need not be surprised by dialogs shown by a background
operation</li>
  <ul>
    <li>should improve the #requestInUI() support to be less obstrusive</li>
    <li>plug-ins should start using the #requestInUI() and provide
feedback to the UI team.</li>
    <li><span style="color: rgb(255, 102, 102);">proposal is to remove
IProgressService#requestInUI - nobody is using and far away from being
real.</span><br>
      <br>
    </li>
  </ul>
  <li>plug-ins have to consistently shows their results and progress in
the same way.</li>
  <ul>
    <li style="color: rgb(255, 102, 102);">if a view is affected by a
background job, it only makes sense
that the view's context can be used to see the progress and cancel the
operation.</li>
    <li style="color: rgb(255, 102, 102);">Decide if title bar status
and a cancel button is good pratice</li>
    <li><span style="color: rgb(255, 102, 102);">Alternative is to have
a re-usable progress widget that could
be used to embed progress in a view.</span></li>
  </ul>
</ul>
<h3>Meeting Summary 2004-03-31</h3>
Attendees: Mike Wilson, Jean-Michel Lemieux, John Arthorne, Tod
Creasey, Erich Gamma, Michael Van Meekeren, Andre Weinand <br>
<br>
First dynamic team meeting. We reviewed the items listed in the summary
section and have agreed on the following work to improve the background
job support (some items don't have names - these are decisions that
we're made but don't have an immediate action item):
<ul>
  <li>(Tod and Michael) Add support for showing a modal dialog when a
user job is run. <br>
  </li>
  <ul>
    <li>The dialog will allow the user to 'run in the background'&nbsp;
(e.g. the default button) at which point the dialog will collapse into
the progress status line. Once collapse there won't be a way to get the
dialog back (related to improved look and feel for progress view).<br>
    </li>
    <li>The dialog will also have a details button that will show the
other active jobs.</li>
    <li>There will be a workbench preference for always running jobs in
the background.</li>
    <li style="color: rgb(0, 0, 0);">(optional) jobs will be able to
know if&nbsp; they are being run in the modal dialog and may decide to
skip certain prompts in that case</li>
  </ul>
  <li style="color: rgb(0, 0, 0);">(Erich) Improve look and feel of
progress view</li>
  <ul>
    <li style="color: rgb(0, 0, 0);">Move away from the tree view and
instead provide a similar UI than the progress dialog (e.g. including
progress indicator).</li>
    <li style="color: rgb(0, 0, 0);">Erich is to prototype</li>
  </ul>
  <li style="color: rgb(0, 0, 0);">(Erich) Investigate showing progress
control in a view<br>
  </li>
  <li style="color: rgb(0, 0, 0);">(Tod and Michael) Add affordance in
the progress status line for the progress view</li>
  <ul>
    <li style="color: rgb(0, 0, 0);">some ideas included adding a job
count, but for the record MVM doesn't think this is a good idea.<br>
    </li>
  </ul>
  <li style="color: rgb(0, 0, 0);">(John) Add support for the Job API
so that the UI can pass additional information to the running job</li>
  <ul>
    <li style="color: rgb(0, 0, 0);">This would be used to let jobs
know if they are being run modally.</li>
  </ul>
  <li style="color: rgb(0, 0, 0);">(Tod and Michael) Improve view tab
highlight support</li>
  <ul>
    <li style="color: rgb(0, 0, 0);">Allow a view to highlight when an
interesting job familly is run</li>
    <li style="color: rgb(0, 0, 0);">Allow a view implementor to
schedule a job in the view (this already exists but will have to work
for multiple workbenc windows)<br>
    </li>
    <li style="color: rgb(0, 0, 0);">Allow a view implementor to
highlight that there are interesting things in the view</li>
  </ul>
  <li style="color: rgb(0, 0, 0);">We decided that
IProgressService#requestInUI() should be removed as API. It isn't used
and would take too much effort to make usable for 3.0 As a side effect
we won't have a non-intrusive notification API in 3.0, and background
jobs will have to bug the user with modal dialogs or another domain
specific mechanism.</li>
  <li style="color: rgb(0, 0, 0);">Cancellation support can be added to
a view (e.g the search view) if it makes sense. There will not be any
workbench support for automatically adding a cancel button.</li>
</ul>
<h3>Meeting Summary 2004-04-01</h3>
Attendees: Mike Wilson, Jean-Michel Lemieux, John Arthorne, Tod
Creasey, Erich Gamma, Andre Weinand <br>
<br>
<ul>
  <li>New progress view<br>
    <br>
Erich had prepared a demo of an improved progress view. There were some
discussion points about support from Core and UI to implement this for
real.<br>
    <br>
    <img style="width: 438px; height: 190px;" alt=""
 src="images/new_progress_view1.JPG"><br>
  </li>
</ul>
<ul>
  <ul>
    <li>(John) Job icon will be passed via the new Job properties API.
A default icon will be available when no icon is available.</li>
    <li>The view could leverage jobs that return IStatus.INFO and
display additional text for those finished jobs. IStatus (e.g. can be
obtained via Job.getResult() or IJobChangeListener.done(Job, IStatus)).</li>
    <li>(Tod) Erich needs an an example of how to hook this into the
existing progress support in the workbench.<br>
    </li>
    <li>(Optional) could provide an API so that a job could provide an
action that would 'go to' the results for the job.<br>
    </li>
  </ul>
</ul>
<ul>
  <li>If a job can block a user initiated action the job must be a
"USER" job.</li>
  <li>(Tod) Searching for markers should not acquire locks or instead
use the new
job API to isBlocking. Then just auto-cancel the job to allow the user
initiated job.</li>
  <li>(John) New API on job so that a job can determine if it's
blocking a modal job (Job.isBlockingModal).</li>
  <li>Status shouldn't be at 0% too long. Why, it should be at least
some number larger than zero. PR these cases.</li>
  <li>View progress consistency</li>
  <ul>
    <li>(Jean-Michel) cancel button should be made available in the
view.<br>
    </li>
  </ul>
  <ul>
    <li>(Jean-Michel) italitize labels for busy indicators instead of
changing font color. (Synchronize View will be updated)<br>
    </li>
  </ul>
  <ul>
    <li>guideline for views - half-busy can't be default because we
don't want to enforce it but UI has support for it via the
IWorkbenchSiteProgressService.<br>
    </li>
  </ul>
</ul>
<div style="margin-left: 40px;">By next week we should have a hooked-up
progress view with the required APIs from core to display icons and
pass-in the properties. Tod should have a prototype of the modal 'run
in background' dialog as well as the job familly support for the
workbench parts.<br>
</div>
<h3>Meeting Summary 2004-04-01</h3>
<ul>
  <li>Job equals USER.</li>
  <li>Wizards - will be happy with showing the dialog for USER jobs,
lower priority for enabling the progress indicator in wizards.<br>
  </li>
  <li>Italic font support in viewers (57425)<br>
  </li>
  <li>Job famillies<br>
schedule via the site, run the job with belongsTo()<br>
  </li>
  <li>Progress View<br>
- progress groups<br>
- INFO status of jobs</li>
  <li>Bolding of views (if focus bold remove)</li>
  <li>Italic support similar than bolding (view can set busy)<br>
    <br>
  </li>
</ul>
<div style="margin-left: 40px;"></div>
<h3><span style="color: rgb(255, 102, 102);"></span></h3>
</body>
</html>
